remove_index is called by name: inside a change migration, which makes the migration irreversible on rollback (Rails can’t reconstruct the removed index definition from the name alone). Consider switching to an explicit up/down (or reversible) that re-adds the original unique index on creator_id in down, and/or use remove_index :schools, :creator_id so Rails can invert it.

The new partial index is given a non-standard name (index_schools_on_creator_id_active_only). For consistency with the existing partial unique indexes on schools (e.g. index_schools_on_reference), consider reusing the conventional name index_schools_on_creator_id for the replacement index to reduce future migration complexity.

I don't have a preference either way. I don't see any problem with the more descriptive name as you only tend to refer to index names from within other migrations. I think there is a limit to the name length but this would likely be within it.

I would choose what you think is clearer.

Test coverage: this changes creator_id uniqueness semantics to allow reuse when the existing school is rejected. Please add/adjust specs to cover the new behavior (duplicate creator_id allowed when the other record has rejected_at set, but still rejected when both are active).

Test coverage: .find_for_user! now excludes schools created by the user if they are rejected (rejected_at set). Add a spec for the rejected-school case (e.g., creator has only a rejected school -> RecordNotFound, and creator has both rejected + active -> returns the active one).

The down migration recreates a global unique index on creator_id. After this change is deployed, the table may legitimately contain multiple rows with the same creator_id (as long as only one is active), so rolling back would fail when re-adding this index. Consider marking the migration as irreversible, or adding a rollback strategy (e.g., clean up/merge duplicate rows or raise with a clear message before attempting to add the unique index).

This risk here is that if we did roll back, and the remove_index succeeded, but the add_index didn't, we would could get duplicates.

This is a small risk as it only applies if we decide to manually roll back the code and migrations so I don't have a strong preference as to if it's worth changing or not - up to you.

This change introduces new behavior (creator_id can be reused when the existing school is rejected, and .find_for_user! should ignore rejected schools). There are existing model specs for creator_id uniqueness and .find_for_user! (spec/models/school_spec.rb), but they don't appear to cover the rejected-school cases. Please add/adjust tests to assert that a second school with the same creator_id is valid when the first has rejected_at set, and that .find_for_user! returns the active school (or raises) when only a rejected school exists.